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1 Introduction 

This document describes 3 rd year accomplishments and summarizes overall project 
accomplishments. Included as attachments are all published papers from year three. 
Note that the budget for this project was discontinued after year two, but that a residual 
budget from year two allowed minimal continuance into year three. 

2 Third Year Accomplishments 

2.1 Initial Investigations into Log-File Based Reverse Engineering. 

Phase 3 of the project was to involve the investigation of approaches for integrating 
formal and informal approaches for reverse engineering in order to support software 
reuse. While the third year budget was cut, we were able to use year 2 residuals to 
begin investigations in this area. Specifically, we began looking at an approach for 
combining the use of informal information such as log-file traces and structural diagrams 
with formal approaches such as model checking. 

Software reverse engineering is defined to be a process of analyzing software 
components and their interrelationships in order obtain a description of the software at a 
high-level of abstraction. Approaches for reverse engineering have been suggested 
that address the reverse engineering problem from a wide variety of views ranging from 
structural makeup to obsen/able behaviors using a wide variety of techniques covering 
both static and dynamic analysis. 

A common activity that occurs within the software development community is the use of 
log files to generate traces of observed software behavior. Several different 
approaches for creating log files exist including the use of compiler directives at the time 
of development and post-development instrumentation. 

As a resource for reverse engineering, a log file has the advantage of being an accurate 
account of software behavior. However, a disadvantage is that the log file potentially 
provides only a subset of possible behaviors of the software. As a result, to mitigate the 
risk of using log files as a source of information for whatever reason, approaches such 
as adequate testing are needed to ensure that a log file trace provides a reasonable or 
adequate amount of behavioral coverage. 



Model checking approaches work by using exploration to determine whether certain 
temporal and safety conditions exist within the state space of some state-based model. 
Model checking, using tools such as Spin and SMV, has gained much attention recently 
due to many factors including the fact that it is relatively lightweight when compared to 
other formal approaches such as theorem proving. In this phase, we initiated 
investigations on approaches to reverse engineering that combine the use of model 
checking and log file analysis to reconstruct software architectures for the purpose of 
both understanding behavior and facilitating architecture level reuse. 

2.2 Service-Based reuse. 

During Phase 3 we also continued our investigations into the use of service-based 
software reuse as a means for implementing systems once individual components have 
been reverse engineered. Specifically, we developed approaches for achieving 
integration at run-time using adapted legacy components. 

Service-based technologies are mechanisms whereby access to information and 
behavior is no longer constrained by traditional company and organizational boundaries. 
Web Services, for instance, employ broker-based middleware that use internet 
protocols such as HTTP and XML, allowing information and data to be provided by 
service providers and consumed by clients over the internet. A service-based 
development paradigm, or services model, is one in which components are viewed as 
services. In this model, services can interact with one another and be providers or 
consumers of data and behavior. Applications built within this paradigm dynamically 
integrate services at runtime based on available resources which facilitates the creation 
of a federation of services (e.g., new "super-services") that can evolve over time. 

Some of the defining characteristics of service-based technologies include modularity, 
availability, description, implementation-independence, and publication. In the service- 
based development paradigm, a primary focus is upon the definition of the interface 
needed to access a service (description) while hiding the details of its implementation 
(implementation-independence). Since the client and service are decoupled, other 
concerns such as side effects become non-factors (modularity). One of the potential 
benefits of using a service-based approach for developing software is that at any given 



time, a wide variety of alternatives may be available that meet the needs of a given 
client (availability). As a result, any or all of the services may be integrated with a client 
at run-time (published). 

This phase of the work involved the development of an architecture-based approach for 
the creation of services and their subsequent integration with service-requesting client 
applications. The technique utilizes an architecture description language to describe 
services and achieves run-time integration using current middleware technology. The 
approach itself is based on a proxy model whereby the “glue” code for both services 
and applications that make use of the services is automatically generated. The Jini 
interconnection technology is used as a broker for facilitating service registration, 
lookup, and integration at runtime. 

3 Tools 

Source to XML generator. As an add-on to previous tools, we developed a translator 
that converts an intermediate format into an XML-based representation called GXL. 
Further tools were planned that would have used this representation to implement 
formal specification generators from source code . 

4 Deviations 

+ Modified scope due to budget cut. The scope was significantly modified due to the 
elimination of the third year budget. Specifically, we were unable to complete tool 
construction, which would have provided a seamless environment for discovery of 
interfaces, adaption of components, and integration. This impacted primarily our 
ability to create sophisticated search capabilities. 



5 Third Year Papers Published 

[1] “Automated Support for Service-Based Software Development and Integration , 
(with Sudhakiran V. Mudiam and Timothy E. Lindquist), submitted to the Journal of 
Systems and Software - Special Issue on Automated Component-Based Software 
Engineering, Oct. 2002. 

[2] "Using Log Files to Reconstruct State-Based Software Architectures", (with Shilpa 
Murthy), WCRE'02 Workshop on Software Architecture Reconstruction, September 
2002 . 

[3] *"A Novel Service-Based Paradigm for Dynamic Component Integration", (with 
Sudhakiran V. Mudiam and Timothy E. Lindquist), in the AAAI-02 Workshop on 
Intelligent Service Integration, July 2002 

6 Project Activities and Results 

6.1 Project Activities 

The following is a listing of all of the investigations that occurred during the funding 

period. 

1 . Service-Based Software Reuse 

a. Component Wrapping 

b. System Integration 

2. Alternative Approaches to Reverse Engineering 

a. Graph-Based Approaches (Component Reuse) 

b. Log-File Based Approach (Architecture Reuse) 

3. Tool Development 

a. Reverse Engineering Tools 

i. Component Wrapping Tools 

ii. Reverse Engineering Tools 

1 . Dependency Graph Generator 

2. Code parser and Visual Browser 

3. C to XML Code Generator 


6.2 Findings 

The primary contribution of this research was the recognition of a move towards 
service-based software development approaches. Recent introduction of technologies 
such as .NET are an indication of the emergence of such work. The research 
performed under this grant directly addressed service-based issues from the standpoint 



of legacy system and component integration. Specifically, our work was aimed at 
providing infrastructures that support discovery and specification of components in order 
to support eventual reuse and integration of those components into new applications. 

6.3 Second Year Results 

6.3.1 Tool Development 

During the second year of the project, construction of a preliminary version of the 
reverse engineering support tool was completed and supports the following features: 

• Analysis of ANSI C programs 

• Construction of graphical representations of source code 

• Clustering of graph based representations of source code using a number of 
criteria 

The tool development was partitioned into two separate projects. The first involved the 
development of a parser for the C program language. The second involved the 
development of a graphical user interface as well as the appropriate clustering routines. 

6.3. 1.1 Parsing 

The parsing project involved the creation of a Java based parsing system that can be 
used to support the construction of reverse engineering tools and facilitate analysis of C 
source code modules. The parsing system was created using Metamata’s parser 
generator JavaCC, JJTree (JavaCC’s associated tree building tool), and the modified 
JavaCC provided C language grammar [1]. In addition, a second intermediate 
representation was developed that grouped language constructs in a manner similar to 
the grammar [3,4], This was done to help provide for easier analysis, traversal, and 
display of the C Source by the reverse engineering tool. The parser system can be built 
using the tools and files given below. Once the parser is built, it can be used to parse 
input C source text files. Output generated by the parser will be two object files 
corresponding to the Abstract Syntax Tree for the source code and the Statement Class 
Hierarchy Representation (described further below and in API documentation for this 
module). These files are saved to disk with the names <SourceFile>.ast and < 
SourceFile >.stm, where < SourceFile >.c is the file being parsed. 



6.3.1. 2 Interface and Analysis 

The analysis project involved the creation of a Java based reverse engineering system 
that can be used for the analysis of C source code modules. Based on a second 
intermediate representation generated by a JavaCC-based parser system, the reverse 
engineering system provides graphic multi-views for easier analysis, traversal and 
display of the C source codes. The system includes a source code browser, call graph 
viewer and global graph analyzer (with clustering capabilities). The graphical user 
interface was developed using Java/Swing components. 

The system provides four patterns for clustering components within the global graph: 

1. Clustering by file: the set of functions contained in the same source file are 

grouped together into one cluster. 

2. Clustering by support library: software systems may use a number of functions 

that are accessed by the majority of its subsystems. This pattern groups 
such functions together into one subsystem. 

3. Clustering by central dispatcher: systems commonly contain a small number of 

resources with a large out-degree. An example is a driver function that 
calls many other functions. 

4. Clustering by Subgraph: This pattern looks for a particular type of subgraph in 

the system's graph. 

6.3.2 Papers Published 

The following sections describe a pair of papers that were published as a result of the 
sponsored project. 

6.3.2. 1 An Investigation into the Connectivity Properties of Source-Header Dependency 
Graphs 

The task of understanding, modifying, and maintaining large systems can be 
intimidating and frustrating, especially in environments where staff turnover rates are 
high. The cognitive models used to tackle these tasks consist of top-down, bottom-up 
and hybrid techniques. Bottom-up approaches focus on the object of study with the 
perspective that direct source code analysis leads to formation of behavioral and 



structural abstractions. Top-down approaches focus on successive refinements of 
candidate designs with verification and validation of recovered designs against the 
implemented software artifacts. Hybrid approaches use a combination of both top-down 
and bottom up techniques in order to support a vertical analysis of a system. 

Software artifacts are often organized at several different levels of discernible 
abstraction including files, procedures, and blocks. Each of these levels of abstraction 
present challenges to the maintainer. At the level of a file, the goal of the maintainer is 
to generate a high-level, informal model. At the level of a function and procedure, a 
maintainer is interested in constructing detailed structural models as well as determining 
the intended and actual behavior of the source code. 

A modularization is a partitioning of a software system into components based on a 
variety of criteria, each depending on the approach and level of abstraction. Recent 
approaches have investigated the effectiveness of traditional clustering techniques and 
genetic algorithms for modularization at the file level of abstraction. 

A source-header dependency graph is a bipartite graph that is formed by flattening 
include file dependencies and enumerating source file to header file dependencies. In 
this paper, we describe an approach for identifying candidate modularizations of 
software systems by analyzing connectivity properties of source-header dependency 
graphs. These modularizations provide information that can lead to coarse-grained 
reuse of source code and are a perfect complement to our earlier work. 

6. 3. 2.2 A Suite of Tools for Facilitating Reverse Engineering Using Formal Methods 
It is well-known that the maintenance of software is one of the most costly aspects of 
software development. As a program evolves, it becomes increasingly difficult to 
understand and reason about changes to source code. Eventually, if several changes 
to software are made without a corresponding modification of the software 
documentation, reverse engineering and design recovery techniques must be used in 
order to understand the current behavior of a system. Software reverse engineering is 
defined as the process of analyzing a subject system in order to identify components 
and component interrelationships and to create representations of that system in other 
forms or at other levels of abstraction. Several approaches to reverse engineering and 



design recovery have been suggested and include techniques for deriving structural 
abstractions and identifying plans embedded in code. 

In our previous investigations, we described a formal technique for reverse engineering 
that involves two phases. The first phase constructs low-level, as-built specifications 
from program code. The specifications recovered from this phase are considered to be 
as-built since they describe a system as it was implemented rather than how the system 
was designed. The second phase of our investigations into reverse engineering 
involves the derivation of high-level abstractions from as-built specifications. By 
constructing high-level abstractions, several activities are facilitated, including high-level 
reasoning, program understanding, and software reuse. 

One of the attractive properties of formal methods is that formal languages with well- 
defined syntax and semantics facilitate the construction and use of automated support 
tools. In addition, since manual application of formal techniques can be prone to errors, 
automated support is desirable. The size of non-trivial programs ranges from the tens 
of thousands to perhaps even millions of lines of code. Given the combined context of 
formal methods and program analysis, the construction of automated support tools is 
well-motivated. In this paper, we describe the development of several tools that have 
been designed to support a formal approach for reverse engineering. Much of this work 
was based on previous work that served as the precursor to the project funded under 
this grant. 

6.4 First Year Results 

6.4.1 Development of a Reverse Engineering Support Tool 

Our primary efforts during the funding period have been directed towards the 
construction of a support tool for deriving formal specifications from program code. 
Specifically, we have defined requirements for the support tool, performed several 
design activities, and have commenced development. The purpose of this tool is to 
support two complementary reverse engineering activities. That is, the tool will support 
the construction of both informal and formal specifications from source code. 



The informal component of the tool is intended to support techniques for generating 
graphical specifications of programs including the construction of data flow diagrams 
and call graphs using approaches such as Software Reflexion [5]. The formal 
component of the tool will support the approach developed by the PI for generating 
strongest postcondition specifications from program code [3]. 

The context for the reverse engineering support tool is shown in Figure 1, where an 
input program is analyzed by the tool along with assistance from the analyst to produce 
an output specification. The output specification can take many forms including a formal 
specification or an informal specification (e.g., diagrams). The analyst (user) can 
provide information at various points in the analysis via modification of source code 
annotations during formal analysis or by guiding the encapsulation/abstraction process 
during informal analysis. 



Figure 2 High-Level Architecture 









Figure 1 A2000 Context Diagram 

The high-level architecture of the A2000 reverse engineering system is shown in Figure 
2, where the system is decomposed using a layered architectural style. The user- 
interface component provides the interaction point with the user and the file 
management system represents an interface to a mechanism for managing input and 
output files. The primary challenges for constructing the support tool lies in the 
development of the Source Code Processor, Structural Analysis, and Logical Analysis 
components. Each of these components embodies the heart of the reverse engineering 
system as they are used to for front-end and back-end processing of source code. 

6.4.2 An Architectural Based Approach for Synthesizing Wrappers 
In software organizations there is a very real possibility that a commitment to existing 
assets will require migration of legacy software towards new environments that use 
modern technology. One technique that has been suggested for facilitating the 
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migration of existing legacy assets to new platforms is via the use of the adapter design 
pattern, also known as component wrapping. We developed an approach for facilitating 
the integration of legacy software into new applications using component wrapping. 
That is, we demonstrate the use of a software architecture description language as a 
means for specifying various properties that can be used to assist in the construction of 
wrappers. In addition, we show how these wrapped components can be used within a 
distributed object infrastructure as services that are dynamically integrated at run-time. 

This work provides a complementary approach to the one to be supported by the work 
described in Section 1.1 for constructing software repositories that can be subsequently 
searched using formal and informal techniques. Specifically, the wrapping technique 
can be used to adapt and store existing components in libraries. The approach 
supports the use of the Jini interconnection technology and is supported by a tool that 
has been constructed using the AcmeLib toolkit [2]. Figure 3 depicts a session of the 
Acme Studio tool [1] that depicts the graphical specification of a legacy RCS component 
with two ports called Chkln and ChkOut, which correspond to the programs ”ci” and 
"co", respectively. By specifying these legacy programs as ports to a component, use 
of several programs as federated services is facilitated. In addition, by using a 
specification medium such as Acme, legacy components can integrated into the 
specification of new software architectures, thus achieving a form of software reuse. 
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Abstract 

We are developing a novel service-based paradigm 
for dynamic component integration that facilitates 
the creation of Intelligent Services from COTS 
(Commercial Off The Shelf) components, legacy 
components, and application frameworks by us- 
ing techniques such as mediation and adaption or 
“wrapping”. This framework supports the con- 
struction of applications by dynamically integrat- 
ing these services at run-time based on available 
resources and allows for a federation of services 
that can evolve over time. As a part of the ongo- 
ing research effort we are utilizing an architecture 
based specification language that enables us to au- 
tomate the process of creating these intelligent ser- 
vices. 

Introduction 

In the past, software reuse, and especially Component 
Based Software Engineering (CBSE) have been in the 
spotlight as various component technologies have ma- 
tured. CBSE is much more than simply using object 
request brokers, setting up a library of useful code, 
or modular development. It involves building, ac- 
quiring, assembling and evolving systems. Tradition- 
ally, in CBSE technologies, several components are 
packaged together to create software systems. Emerg- 
ing concerns include multiple suppliers of components 
that provide the same functionality, coping with mul- 
tiple versions, and configuration of components. Cur- 
rently, CBSE addresses issues and technologies such 
as Commercial-Off-The-Shelf (COTS) components, in- 
built components, and application frameworks. Emerg- 
ing technologies of component integration include, En- 
terprise Java Beans (Thomas 1998), CORBA (Obj 
1996), Jini (Richards 1999), Microsoft’s DNA(Kirtland 
1999), DCOM(Eddon & Eddon 1998) and IBM’s San 
Francisco (Monday, Carey, & Dangler 1999). All these 
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technologies provide a component model where a pre- 
defined infrastructure acts as “plumbing” that facili- 
tates communication between components. Tools and 
environments supporting these technologies are being 
widely used in the industry and continue to provide 
many benefits. 

We are developing a novel service-based paradigm 
for dynamic component integration that facilitates the 
creation of Intelligent Services from COTS (Commer- 
cial Off The Shelf) components, legacy components, 
and application frameworks by using techniques such 
as mediation and adaption or “wrapping”. This frame- 
work supports the construction of applications by dy- 
namically integrating these services at run-time based 
on available resources and allows for a federation of ser- 
vices that can evolve over time. As a part of the ongo- 
ing research effort we are utilizing an architecture based 
specification language that enables us to automate the 
process of creating these intelligent services (Gannod, 
Mudiam, & Lindquist 2000). 

The remainder of this paper is organized as follows. 
The next section introduces our approach for applica- 
tion construction based on the use of intelligent ser- 
vices. An example using the approach is described in 
the following section, and the balance of the paper dis- 
cusses related work, conclusions and future investiga- 
tions. 

A New Paradigm 

We are developing an approach based on a new 
paradigm that looks at software reuse from a different 
perspective in which components are viewed as services 
available on a network. In this paradigm, components 
are dynamically composed into federations to make up 
an application (Mudiam 2000). The key features of our 
approach within this paradigm are: 

• Components of varying granularity are bundled as 
“intelligent services” and made available on a net- 
work. 

• The paradigm provides an integration framework, or 
middleware, that allows for the dynamic integration 
of these components (bundled as intelligent services) 
at run-time. 


• The paradigm facilitates the use of various patterns of 
interaction (architectural styles) between clients and 
intelligent services. 

• The intelligent services provide a clear set of inter- 
faces that are discovered dynamically at run-time and 
achieved using filters and adapters. 

The process of component integration consists of the 
following steps. 

1. Specification of the components as services. 

2. Generation of the services along with the appropriate 
adapters and storing them to a repository. 

3. Specification of a client to make use of services from 
the repository. 

4. Generation of the client. 

5. Execution of the client, performs the integration of 
the specified services at runtime. 

Steps 1 and 2 are typically performed only once for 
each service while Steps 3 through 5 are performed as 
needed for each application. One of the primary goals 
of this work is the use of automatic synthesis to gen- 
erate the source code necessary to achieve service in- 
tegration. Our preliminary investigations have yielded 
an approach for generating wrappers of legacy applica- 
tions for use as services (Gannod, Mudiam, & Lindquist 
2000). In this work, a specification of a legacy software 
is created that defines the interface to a potential ser- 
vice. Second, the appropriate adapter source code is 
then synthesized based on the specification. 

In order to specify how applications are to be inte- 
grated, we use the ACME architecture description lan- 
guage (ADL) (Garlan, Monroe, & Wile 1997) to de- 
scribe both the available services as well as the client 
components that utilize those services. These specifi- 
cations capture the interface of the components in such 
a way that the services can be regarded as black-boxes 
while remaining loosely coupled from implementation 
details. 

Once the services are generated and stored in a repos- 
itory, clients can make use of these services by identi- 
fying a general class of service that is required and the 
architectural style is necessary to properly interact with 
a client. This work addresses several issues that need to 
be considered during application specification and con- 
struction including: 

• The specification of application architectures 

• The specification of a component type in order to 
manage style interactions 

• Graphical user interface integration including the use 
of shared graphical features 

Again, using the ACME ADL, an application ar- 
chitecture is specified in order to describe the client 
composition and to identify the service classes that are 
needed by the application. Using this specification, the 
source code necessary to realize integration is generated 


(but is not bound to specific services). The remaining 
source code for the client, as with all applications, is 
provided by the user. 

Integration of all services in our paradigm is per- 
formed with the execution of clients as each service be- 
comes available. At first a client registers with a lookup 
service. Once services become available and join the 
network, the client is notified. The client integrates with 
the services by performing the GUI component integra- 
tion as well as the service adapter integration and uti- 
lizes the service. 

The research described above makes use of 
Jini (Richards 1999) technology to realize service in- 
tegration. The components are wrapped as Jini services 
and we make use of the discovery and join mechanism 
to enable services join a Jini network. 

Example 

Figures 1 and 2 depict specifications of a client compo- 
nent and a number of services, respectively. In this ex- 
ample, the client consists of an editor that needs to uti- 
lize version management, printing, and compiling ser- 
vices. When the client runs, it joins the Jini network 
using Jini’s discover and join protocol. As shown in the 
specification in Figure 1, the services that are required 
by the client are described as ports to which services 
will be bound. 

Component Editor = { 

Properties { 

Part-of-client : 

string = "true"; 

GUI-CodeFile : 

string = "ClientGUICode . j ava ” ; 
Component- type : 

string = "Call Return"; 

}; 

Port VM_Port = { 

Properties { 

Port- type : 

string = "caller"; }; 

}; 

Port COMPILING_PORT = { 

Properties { 

Port-type : 

string = "caller"; }; 

}; 

Port PRINTING_PORT = { 

Properties { 

Port-type : 

string = "caller"; }; 

>; } ; 


Figure 1: Client Specification 

The specifications of the services, as shown in Fig- 
ure 2, describe each of the available services in the in- 
tegration network. In this example we show only the 
specification of the RCS service and provide stubs for 
other services. Note that the other services would in- 
deed be specified in the same manner as the RCS ser- 
vice. Each of the port specifications in a service com- 



ponent describe associated services. As such, the RCS 
service could potentially have sub-services for check in 
and check out. 

Component RCS = { 

Properties { 

Component- type : 
string = "Call Return"; 

} ; 

Port Chkln = { 

Properties { 

Signature : 

string = "String filename, 

String params, String filedata " ; 
Return : 

string = "Boolean result"; 

Cmd : 

string = "ci + filename + params"; 
Pre : 

string = 

" WriteFileData (filedata, filename) " ? 
Post : 

string = " " ; 

Interface : 

string = " Vers ionMa nag ement " ; 

Path : 

string = " C ; \ \RKTOOLS\ \BIN\ \CI . EXE 
Port- type : 

string = "callee"? 

Component Lzpr = { 

Properties { 

Component- type : 

string = "Call Return"; 

}; 

Port Print = { 

Properties { 




Editor Window.. 





Figure 3: Initial Client 

Related Work 

Sullivan et al. look at systematic reuse of large-scale 
software components via static component integra- 
tion (Sullivan et al. 1997). That is, they use an 
OLE-based approach for component integration. To 
demonstrate the use of their scheme, they developed a 
safety analysis tool that integrates application compo- 
nents such as Visio and Word. In our approach we use a 
dynamic approach for component integration and thus, 
can utilize a wide variety of components whose inter- 
faces are discovered at run-time. 

CyberDesk (Dey et al. 1997) is a component-based 
framework written in Java that supports automatic inte- 
gration of desktop and network services. This frame- 
work is flexible and can be easily customized and ex- 
tended. The components in this framework treat all data 
uniformly regardless of whether the data came from a 
locally running service or the World Wide Web. The 
goal of this framework is to provide ubiquitous access 
to services. This approach is similar to our proposed 
approach in that they use a dynamic mapping facility to 
support run-time discovery of interfaces. 


};};}; 

Component Javac = { 

Properties { 

Component- type : 

string = "Call Return"; 

} ? 

Port Compile = { 

Properties { 


}; ); ) ; 


Figure 2: Services Specification 

Initially, when no services are available, the client 
only has its editing GUI component as shown in Fig- 
ure 3. However, since the client has access to the list 
of services that it needs, it utilizes the lookup services 
on the Jini network in order to complete service integra- 
tion. As each service comes up and joins the Jini net- 
work, the client learns its existence and integrates them 
into the client. The Figure 4 shows the result of the in- 
tegration once all the services have joined the network. 
In this example, we have a version management ser- 
vice called the RCSService , a compiling service called 
JavacService and a printing service called IzprService. 


Conclusions 

The availability of components on a network that pro- 
vide services at run-time has many potential applica- 
tions including the use of heterogeneous components 
executing in distributed environments. Enabling tech- 
nologies such as Jini allow for dynamic component 
integration. We have described an architecture-based 
methodology of building components for reuse, and 
later using them with in a larger context to build ap- 
plications. 

We are currently building an environment for sup- 
porting the specification and synthesis of applications 
that utilize services through dynamic integration. The 
current state of this work includes tools for sythesizing 
both service and client integration code. We have used 
these tools to generate examples including the one de- 
scribed in this paper. Our future investigations include 
developing an approach for dynamically generating me- 
diators to facilitate service interactions that bypass the 
need to communicate via client applications. 
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Abstract 

A common activity that occurs within the software devel- 
opment community is the use of log files to generate traces 
of observed software behavior. As a resource for reverse 
engineering , a log file has the advantage of being an ac- 
curate account of software behavior. Model checking ap- 
proaches work by using exploration to determine whether 
certain temporal and safety conditions exist within the state 
space of some state -based model. In this paper we describe 
an approach to reverse engineering that combines the use 
of model checking and log file analysis to reconstruct soft- 
ware architectures. 

1 Introduction 

Software reverse engineering is defined to be a process 
of analyzing software components and their interrelation- 
ships in order obtain a description of the software at a 
high-level of abstraction [1]. Approaches for reverse engi- 
neering have been suggested that address the reverse engi- 
neering problem from a wide variety of views ranging from 
structural makeup to observable behaviors using a wide va- 
riety of techniques covering both static and dynamic anal- 
ysis. 

A common activity that occurs within the software de- 
velopment community is the use of log files to generate 
traces of observed software behavior. Several different ap- 
proaches for creating log files exist including the use of 
compiler directives at the time of development and post- 
development instrumentation [2]. 

As a resource for reverse engineering, a log file has the 
advantage of being an accurate account of software behav- 
ior. However, a disadvantage is that the log file potentially 
provides only a subset of possible behaviors of the soft- 
ware. As a result, to mitigate the risk of using log files as 
a source of information for whatever reason, approaches 
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such as adequate testing [3] are needed to ensure that a log 
file trace provides a reasonable or adequate amount of be- 
havioral coverage. 

Model checking approaches work by using exploration 
to determine whether certain temporal and safety con- 
ditions exist within the state space of some state-based 
model. Model checking, using tools such as Spin and SMV, 
has gained much attention recently due to many factors in- 
cluding the fact that it is relatively lightweight when com- 
pared to other formal approaches such as theorem proving. 

In this paper we describe an approach to reverse engi- 
neering that combines the use of model checking and log 
file analysis to reconstruct software architectures. The re- 
mainder of this paper is organized as follows. Our ap- 
proach to reverse engineering is presented in Section 2. 
Section 3 presents related investigations and Section 4 
draws conclusions and outlines future investigations. 

2 Approach 

This section describes the underlying conceptual basis 
as well as the reverse engineering approach being used to 
reconstruct software architectures. 

2.1 Underlying Conceptual Basis 

Figure 1 depicts the general context for a software de- 
velopment approach that involves the use of model de- 
velopment, model checking, and log file generation (or 
other debugging approaches). In the general context, the 
relationship between models and programs is labeled as 
implements-models. The semantics of this relationship em- 
phasizes the fact that the model is implemented by a pro- 
gram and that a program is modeled by a model. 

Model checking tools such as Spin [4] facilitate verifi- 
cation of the ordering of events within a model. In Spin the 
verification is achieved using linear temporal logic (LTL) 
while SMV [5] achieves this using computational tree logic 
(CTL). Here we assume the use of Spin and LTL. The 
maps-to relationship between log files and LTL specifica- 
tions emphasizes the analogy between log files and LTL 
specifications. As with the relationship between models 
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and programs, there is a difference in the level of abstrac- 
tion between log files and LTL specifications. 



Figure 1. General Context 


Andrews’ developed an approach to software testing 
based on the concept that given a state-based model such 
as a finite automata or statechart, a program implementing 
the model must generate behaviors that correspond directly 
to events in the model [6]. While the approach does not use 
a specific model checking environment like Spin or SMV, 
the employed verification technique used does achieve sim- 
ilar goals, e.g., verification of the model by using log file 
events to drive model execution. As a result, a situation 
arises as shown in Figure 2(a), where a model is used to 
aid in the development of a program, and a log file is gen- 
erated during program execution. In this case, the model is 
assumed to be correct and thus the verification against an 
LTL specification ignored. If the log file events do not cor- 
respond to model events, then the program is considered 
faulty and must be modified. 



(a) 



(b) 

Figure 2. (a) Testing Context (b) Reverse En- 
gineering Context 


An interesting result can be derived if the relationships 
between program/model and logfile/LTL specification are 
reversed as shown in Figure 2(b). Namely, it provides a 


means for verifying correspondence between existing sys- 
tems and models reconstructed using reverse engineering. 
That is, assuming that the program is correct (e.g., we are 
interested in learning what the program does rather than 
verifying it against requirements) then any log file pro- 
duced is an accurate representation of what happens dur- 
ing execution. Therefore, any model constructed to repre- 
sent the program behavior must at some level generate the 
events found in a log file with the same temporal orderings, 
assuming a well-defined logging policy. 

2.2 Process 

We are currently developing a reverse engineering ap- 
proach based on the context provided in Figure 2(b). The 
approach has four primary steps that are necessary to be 
successful. In Step 1, log files must be generated from the 
program. This step, in some cases, is already completed 
since a common activity for some developers is to generate 
traces as an aid to debugging. However, there is a risk in 
using such traces since the logs can be inconsistently up- 
dated (e.g., not all events are captured). As a result, it is 
necessary to develop logging tools that follow specific log- 
ging policies on what to log and when to log . 

In Step 2, a model must be reconstructed from source 
code and other sources of information. In our technique, 
we assume that the system of study utilizes a state-based 
architectural style and that we are interested in deriving 
high-level state charts as well as some intermediate models. 
Several approaches have been suggested for deriving state 
models from code and other artifacts including the work by 
Systa [7]. In our approach, model construction can be free 
form in the sense that it does not have to be strictly bottom- 
up. In fact, the model can be constructed top-down with 
little or no direct code analysis. As long as the verification 
step ends in a valid model, the approach used for deriving 
the model is unimportant. 

Step 3 involves the mapping of log file events to LTL or 
CTL specifications, with the choice depending on the tool 
used to perform model checking. The mapping of log file 
events to LTL propositions requires the use of event ab- 
straction techniques [9] especially since many events in a 
log file may be decompositions of some higher level event 
that is captured in a model. We are developing an approach 
that will work by partitioning log files into disjoint equiv- 
alence classes of events and mapping a representative of a 
partition to specific events contained in a model. The result 
preserves ordering while relaxing a need for exact event 
mapping. 

Finally, in Step 4, model checking is used to determine 
whether the sequence of events captured in a log file and 
encoded with a LTL specification are consistent with the 
candidate models developed in Step 2. When an invalid 
verification occurs the conclusion that can be drawn is that 
either the model is incorrect, the encoding of the LTL spec- 
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ification is incorrect, or both. In the case of an incorrect 
model, modification and refinement of the model becomes 
necessary. In regards to the correctness of an LTL spec- 
ification, as long as the generated specification preserves 
ordering located in the log file and the propositions corre- 
spond to events in the model, the verification will provide 
accurate results. 

Upon completing the four steps, what an analyst would 
gain is a state-based architectural and design view of a sys- 
tem that has been verified against observable behavior ex- 
hibited by the system of study. Using the evaluation di- 
mensions defined by Gannod and Cheng [8], the abstrac- 
tion distance and traceability of the model from the origi- 
nal source code is influenced entirely by the approach used 
to perform Step 2 rather than by the underlying reverse en- 
gineering framework described here. In terms of accuracy, 
the verification step ensures that the model is accurate with 
respect to generated log files. However, the completeness 
of the verification depends on adequacy criteria used to de- 
termine how many log files to generate. The precision of 
the approach is considered to be high since the representa- 
tion used to encode the models must be format enough to 
employ model checking techniques. 

3 Related Work 

Andrews [6] provides a framework for automatically an- 
alyzing log files using state machines in the context of test- 
ing. The Log Files are created using logging policies and 
a standard format which specifies certain keywords. A log 
file analyzer is specified formally using the Log File Anal- 
ysis Language (LFAL) and is built as a set of parallel state 
machines with each log file machine checking one thread 
of event. 

Basten investigated the use of event abstraction to 
reduce the apparent complexity of distributed computa- 
tions [9]. The work is based on the study of four aspects 
of event abstraction: a model describing primitive behav- 
ior, a formalism for specifying abstract behavior in terms 
of activity and causality, abstract descriptions of behavior, 
and verification of primitive or abstract descriptions against 
specified behavior. 

Systa [7] discusses an experimental environment for re- 
verse engineering Java software with respect to the con- 
cepts of static and dynamic views. These views contain 
overlapping information about software artifacts and their 
relations, which form a connection for information ex- 
change between the views. Static information extracted 
from Java class files is viewed using the Rigi environ- 
ment [10]. The dynamic information generated by run- 
ning the software under a debugger is viewed as scenario 
diagrams using the SCED prototype tool. SCED state di- 
agrams can be synthesized from these scenario diagrams. 
The SCED scenario diagrams are further used for slicing 
the Rigi view and the Rigi view in turn is used to guide the 


generation of SCED scenario diagrams and for raising their 
level of abstraction. 

4 Conclusions and Future Investigations 

Our initial experience with the approach has shown a 
great deal of promise with some moderate risks in each of 
the process steps. An ability to capture appropriate event 
information (Step 1) and map those events (Step 3) are es- 
pecially crucial to the success of the approach since inac- 
curacies in these steps reduce the impact of the verification 
step. 

To date, we have completed the construction of a log- 
ging tool that is based on the use of the Java Debbugging 
Platform [1 1] in order to log events in Java programs with- 
out resorting to behavior modification as is possible with 
code instrumentation techniques. We are currently devel- 
oping tools to support the derivation of LTL specifications 
from log files using event abstraction techniques [9]. 
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Abstract 


A service-based development paradigm is one in which components are viewed as services. In this model, 
services can interact with one another and be providers or consumers of data and behavior. Applications 
built within this paradigm dynamically integrate services at runtime based on available resources. This 
paper describes an architecture-based approach for the creation of services and their subsequent integration 
with service-requesting client applications. The technique utilizes an architecture description language to 
describe services and achieves run-time integration using current middleware technology. 


1 Introduction 


Service-based technologies are mechanisms whereby access to information and behavior is no longer con- 
strained by traditional company and organizational boundaries. Web Services, for instance, employ broker- 
based middleware that use internet protocols such as HTTP and XML [Stal, 2002], allowing information 
and data to be provided by service providers and consumed by clients over the internet. A service-based 
development paradigm, or services model [Fremantle et al„ 2002], is one in which components are viewed 
as services. In this model, services can interact with one another and be providers or consumers of data 
and behavior. Applications built within this paradigm dynamically integrate services at runtime based on 
available resources which facilitates the creation of a federation of services (e.g., new ’’super-services”) that 
can evolve over time. 

Some of the defining characteristics of service-based technologies include modularity ; availability , de- 
scription, implementation-independence , and publication [Fremantle et al., 2002]. In the service-based de- 
velopment paradigm, a primary focus is upon the definition of the interface needed to access a service (de- 
scription) while hiding the details of its implementation (implementation-independence). Since the client 
and service are decoupled, other concerns such as side effects become non-factors (modularity). One of the 
potential benefits of using a service-based approach for developing software is that at any given time, a wide 
variety of alternatives may be available that meet the needs of a given client (availability). As a result, any 
or all of the services may be integrated with a client at run-time (published). 

This paper describes an architecture-based approach for the creation of services and their subsequent 
integration with service-requesting client applications. The technique utilizes an architecture description 
language to describe services and achieves run-time integration using current middleware technology. The 
approach itself is based on a proxy model [Gamma et al., 1995] whereby the ‘‘glue’’ code for both services 
and applications that make use of the services is automatically generated. The Jini interconnection tech- 
nology [Richards, 1999] is used as a broker for facilitating service registration, lookup, and integration at 

runtime. 

The remainder of this paper is organized as follows. Section 2 describes background material in the areas 
of software reengineering, software architecture and the middleware technology we are using to enable 
dynamic integration (i.e., Jini [Richards, 1999]). The proposed approach for constructing services and 
developing service-based applications is presented in Section 3. An example demonstrating the proposed 
approach is described in Section 4, Section 5 discusses related work, and Section 6 draws conclusions and 
suggests further investigations. 
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2 Background 

This section describes background material on specific patterns supported, software architecture and the Jini 
Interconnection Technology. 

2.1 The Proxy Pattern 

Proxy Pattern [Gamma et al., 1995] provides a surrogate or a placeholder for another object to control access 
to it. In this pattern a client accesses a realSubject only via a Proxy. The proxy provides an intermediate 
layer between the client and the realSubject. The proxy acts as a local representative for the realSubject and 
typically lives in the client’s address space. It is necessary for the proxy to provide exactly the same interface 
as the realSubject. All the access to the realSubject from the client have to go thro the Proxy. In most cases 
the client is not even aware of the proxy object and it assumes that it is directly talking to the realSubject. 
Figure 1 shows the interaction between a client and a realSubject via a proxy. In the approach described 
in this paper, the proxy pattern plays a central role in the definition of services as well as the realization of 
service integration. 



Figure 1 : Proxy Pattern [Gamma et al., 1995] 


2.2 The Adapter Pattern 

Re-engineering is the process of examination, understanding, and alteration of a system with the intent 
of implementing the system in a new form [Chikofsky and Cross, 1990]. Since the functionality of the 
existing software has been achieved over a period of time, it must be preserved for many reasons, including 
providing continuity to current users of the software. One approach to re-engineering is to use the adapter 
pattern [Gamma et al., 1995] whereby a legacy interface is converted into a form that a client application 
can utilize. The adapter pattern allows components that otherwise could not work together because of 
incompatible interfaces to be combined to form a new software system. In our approach the adapter pattern 
is used to re-engineer legacy command-line software to provide the software as services. Specifically, in 
terms of the Gamma et al. adapter pattern, we use the concept of the object adapter in the manner shown in 
Figure 2. 

2.3 Software Architecture 

A software architecture describes the overall organization of a software system in terms of its constituent 
elements, including computational units and their interrelationships [Shaw and Garlan, 1996]. In general, an 
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Figure 2: Object Adapter [Gamma et al., 1995] 

architecture is defined as a configuration of components and connectors. A component is an encapsulation 
of a computational unit and has an interface that specifies the capabilities that the component can provide. In 
addition, the interface specifies ways the component delivers its capabilities. The interface of a component 
is specified by the type of the component, by one or more ports supported by the component, and by the 
constraints imposed on the ports of the component, where component types are intended to capture archi- 
tectural properties. Ports are the interaction points through which a component exchanges resources with its 
environment. Port specifications specify the signatures, and optionally, the behaviors of the resource. 

Connectors encapsulate the ways that components interact. A connector is specified by the type of 
the connector, the roles defined by the connector type, and the constraints imposed on the roles of the 
connector. A connector defines a set of roles for the participants of the interaction specified by the connector. 
Connector types are intended to capture recurring component interaction styles. Components are connected 
by configuring their ports to the roles of connectors. Each role has a domain that defines a set of port types 
and only the ports whose types are in the domain can be configured to the role. 

Another important concept in the area of software architectures is the concept of an architectural style. 
An architectural style defines patterns and semantic constraints on a configuration of components and con- 
nectors. As such, a style can define a set or family of systems that share common architectural semantics 
[Medvidovic and Taylor, 1997]. For instance, a pipe and filter style refers to a pipelined set of components 
whereas a layered style refers to a set of components that communicate via hierarchies of interfaces. There 
are several architecture description languages that allow the user to describe the architecture of a system. 

2.4 Jini 

The primary enabling feature of the work described in this paper is the existence of the Jini technology for 
the delivery and management of services. In a typical Jini network, services are provided by devices that are 
connected to the network. Typically these devices consist of a variety of products ranging from cell phones, 
desktop devices, printers, fax machines, and Personal Digital Assistants (PDAs). 

Figure 3 shows the layered architecture of the Jini Interconnection technology where the Jini Technology 
layer provides distributed system services for activities such as discovery, lookup, remote event management. 
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transaction management, service registration, and service leasing. When a device or “service is plugged 
into a Jini network, it becomes registered as a member (e.g., service) of the network by the Jim lookup 
service. When a service is registered, a proxy is stored by the lookup service. The proxy (often imple- 
mented with an adapter) can later be transported to the clients of the service. Once registered, other network 
members can discover the availability of the device (e.g., service) through the lookup service. When a client 
application finds an appropriate device, the lookup service sets up the connection but then is no longer in- 
volved in subsequent interactions between the client and device. In our approach to component integration, 
we use the Jini technology to provide a standard method for registering and connecting a client to corre- 
sponding software components that are acting as services. We are using Jini technology outside the scope 
of its original intention of being able to allow devices to interact with one another by using the discover and 
join protocols supported by this technology to implement service-based software development. 


Application 


Service 

Jini Technology 

Java 


Java 

Technology 


Technology 


Device 


Figure 3: Jini Architecture 

One of the advantages of using this Jini-based integration technique is that it facilitates construction of 
applications “on-the-fly” whereby components can be used on an as-needed basis. Another advantage arises 
from the fact that services must implement a fairly general set of routines in order to participate in a Jini 
network. One of the disadvantages of this approach stems from the fact that the interface to the services 
must be well-defined or must be negotiated between the client and the device upon connection. That is, 
the client must have some knowledge about how to use the service. We have implemented our framework 
on Jini for a number of reasons including the fact that it allows for the creation of federations of services. 
More importantly, an advantage of using Jini over the emerging Web services technologies is that many 
of the current and future capabilities of the web services infrastructure are already supported by Jim, thus 
providing a view into forthcoming capabilities of web service-based software development without needing 
to wait for the completion of development of web service support technology. 

3 Approach 

This section describes the service-based development approach including the techniques used for defining 
services, specifying client applications, realizing integration, and generating glue code. 
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3.1 Overview 


The approach described in this paper follows a services-based model for software development. The method- 
ology that we have developed follows closely the model suggested by Stal [Stal, 2002] for web services, 
although the technology that we are using to realize our approach is Jini [Richards, 1999]. It is our belief 
that the technique is applicable to the web services domain and that translation into that technology would 
require little change at the conceptual level and a modest amount of change at the technology level. 

The approach itself focuses on two concerns with respect to software reuse. That is, it addresses both for 
reuse and with reuse concerns. With respect to for reuse , the approach involves the construction of services 
via the use of adapter and proxy synthesis. Specifically, the methodology involves two steps for creating 
services as follows: 

1 . Specification of the components as services 

2. Generation of the services using proxies via the construction of appropriate adapters and glue code. 
These services are consequently registered and made available on a network. 

In the context of this paper, we address the creation of command-line applications [Gannod et al., 2000] as 
services. As part of our ongoing research work we are investigating approaches for integrating a wide-variety 
of services including web services and .NET components. 

With respect to with reuse concerns, the approach involves the construction of applications using services 
as follows: 

1. Specification of a client to make use of services from the repository or network 

2. Generation of the client (both manual construction of client application specific code and automated 
generation of glue code) 

3. Execution of the client, including integration of the specified services at runtime 

Figure 4 shows a diagram depicting the basic architecture for applications created within the infras- 
tructure described in this paper. Structurally the architecture uses a layered style with a layer of services 
accessed via a layer of proxies. Within our approach, a user (e.g., developer) is responsible for writing 
the source code for the client application along with the specification of the architecture for client. Among 
other things, the client specification contains a description of the basic services that the client application 
will need in order to be a complete system. All other source code, including code necessary to realize the 
connections between the client and employed services, is generated based on the specifications describing 
clients, services, and connectors. At run-time, the services are bound to the client component using the Jim 
lookup service. 
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Figure 4: Basic Architecture 

3.2 Service Generation 

In order to generate services from legacy components, we take the approach of wrapping the components 
by utilizing the interface provided by the component. For example, command-line applications have a well 
defined interface. The interface is based entirely on the knowledge of how these applications are used rather 
than how they work. 

3.2.1 Specification and Synthesis 

The concept of using an adapter for wrapping legacy software is not a new one [Gamma et al., 1995, 
Sneed, 1996, Cimitile et al., 1998, Jacobsen and Kramer, 1998]. As a migration strategy, component wrap- 
ping has many benefits in terms of re-engineering including a reduction in the amount of new code that must 
be created and a reduction in the amount of existing code that must be rewritten. 

In regards to wrapping components, our approach uses two steps. First, a specification of the legacy 
software as an architectural component is created. These specifications provide vital information that is 
required to define the interface to the legacy software. Second, the appropriate adapter source code is 
synthesized based on the specification. 

3.2.2 Specification Requirements 

To aid in the development of an appropriate scheme for the wrapping activity, we defined the following 
requirements upon specifications of the interface to legacy software. 

(51) A sufficient amount of information should be captured in the interface specification in order to mini- 
mize the amount of source code that must be manually constructed. 

(52) A specification of the interface of the adapted component should be as loosely coupled as possible 
from the target implementation language. 
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(S3) The specification of the adapted component should be usable within a more general architectural 
context. 

The requirement SI addresses the fact that we are interested in gaining a benefit from reusing legacy 
software. As a consequence, we must avoid modifying the source code of the legacy software. At the same 
time, we must provide an interface that is sufficient for use by a target application. To provide that interface, 
a sufficient amount of information is needed in order to automatically construct the adapter. 

As an initial investigation into the automated synthesis of the adapters, we selected command-line ap- 
plications as our source of reusable legacy software. Selection of this class of legacy applications addresses 
the modification concern of requirement SI since source code is not available. As such, we are required 
to provide an interface that is based solely on the knowledge of how the application is used rather than 
how it works. In addition, the selection of this class of applications has the consequence of enforcing the 
use of a particular architectural style, as determined by the nature of the legacy application. In this con- 
text, we defined several properties that would be needed to appropriately specify the behavior provided 
by a command-line application including: Signature , Command , Pre , Post, and Path. We identified these 
properties by examining the type of behaviors, inputs, and outputs generally associated with command-line 
applications. 

The Command property identifies the command used to invoke the application while the Pre and Post 
properties identify commands that are contained within the adapter code that will establish preconditions 
and post-conditions on the execution of the legacy component, respectively. Path indicates the path to the 
given command-line application and the Signature property defines the types and names of the expected 
input and output of that application. Here, since we are dealing with command-line applications, the input 
types are expected to be strings. Accordingly, a certain degree of semantic information must be used in 
the name of the input. Fortunately, for command-line applications, these names are typically limited to file 
names and command-line options. 

Table 1 shows the properties used in the specification of services, clients and connectors. A service 
component specification consists of two parts: properties and ports. The properties section describes style 
of the service, while the ports section describes functions provided by the service. In addition, the service 
specifications indicate style-based information as well as conditions or commands that need to be true or 
executed, respectively, in order to establish an environment necessary to use the service. Finally, a key in 
terms of a “service type” (encoded as an Interface property) is used to support a service lookup, which is 
later utilized during application integration. 


7 



Group 

Attribute 

Description 

Sendee Properties 

Component-Type 

Architectural style this component adheres to 

Service Port Properties 

Signature 

Return 

Cmd 

Pre 

Post 

Interface 

Path 

Port-Type 

Shared-GUI 

The port’s signature 

The port’s return type 

The command line program being wrapped 

Pre-processing command 

Post-processing command 

The generic interface implemented by this port 

Path to the wrapped command line program 

The port’s type based on the Component-Type 

Boolean indicating shared (true) or exclusive (false) GUI 

Client Properties 

Part-of-client 

GUI-CodeFile 

Component-Type 

Shared-GUI 

Does this specify the client application 
The filename for client’s GUI code 
Architectural style this component adheres to 
Boolean indicating shared (true) or exclusive (false) GUI 

Client Port Properties 

Port-Type 

Interface 

The port’s type based on the Component-Type 
The generic interface that this port can bind with 

Connector Properties 

Connector-Type 

Architectural style this connector adheres to 

Connector Role 

Prop-Type 

The connectors role based on the Connector-Type 


Table 1: Properties 


The requirement S2 (i.e., the decoupling of a specification from a target implementation language) is 
based on the desire to apply the synthesis approach to a variety of target languages and implementations. In 
addition, this requirement facilitates enforcement of requirement SI by ensuring that new source code is not 
artificially embedded in the specification. While satisfying this requirement is ideal, we found in our strategy 
that a certain amount of implementation dependence was necessary due to the fact that our implementation 
would make use of Jini Interconnection Technology [Richards, 1999]. 

When a component has been wrapped using our technique, an interface is defined that facilitates the use 
of the source legacy software as part of a new application. However, as indicated by requirement S3, it is also 
desirable to be able to use the specification of the adapted component within a more general architectural 
context. That is, it is advantageous to be able to use the specification as part of the software architecture 
specification for new systems. In using a content-rich specification, where interfaces are defined explicitly, 
the added benefit of providing information that can be integrated into an architectural specification of a 
target application is gained. 

In order to realize the requirements placed upon desired interface specifications for legacy software 
wrappers, we used the ACME [Garlan et al., 1997] Architecture Description Language (ADL). Specifically, 
we used the properties section of the ACME ADL to specify the interface features described earlier (e.g, 
Signature, Command, Pre, Post, and Path). ACME is an ADL that has been used for high-level architectural 
specification and interchange [Garlan et al., 1997]. ACME contains constructs for embedding specifications 
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written in a wide variety of existing ADLs, making it extensible to both existing and future specification 
languages. ACME is supported by an architectural specification tool, ACMEStudio [Acme Studio, 2002], 
that facilitates graphical construction and manipulation of software architectures. 

Figure 5 shows a screen capture of an ACMEStudio session in which a component has been specified 
as an aggregation of two wrapped applications expressed as ports. In the figure, the component labeled 
RCS is the aggregate component and consists of two ports, Chkln and ChkOut. These ports are used 
as wrappers for the Revision Control System (RCS) programs ci and co, respectively. The bottom right 
portion of the figure contains a list of the properties used to derive the wrapper along with their corresponding 
values. The amount of knowledge that is required in order to write the wrapper specification is limited to a 
working knowledge of how a legacy application is used. Often this includes knowledge of the command-line 
parameters as well as other bits of information that can be retrieved from manual pages (if they exist) and 
current users. 
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Figure 5: ACMEStudio Session 


Several benefits arise from the use of the ACME ADL to specify the legacy application wrappers. First, 
if the specification of an adapted component is realized as a port, then several such components can be 
aggregated into a single component. As a consequence, the aggregated component can offer each of the 
behaviors as a service through a port interface. For example, as demonstrated in Section 4, the RCS suite 
of applications can be aggregated into a single component that offers services such as check-in and check- 
out via ports of the aggregate component. Second, via the use of ACMEStudio, the specification of an 
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adapted component can be integrated into the specification of target applications. Consequently, software 
architecture analysis techniques that support the use of ACME can be applied to target applications that 
utilize the wrapped legacy software. Finally, since library support for ACME consists of a set of standard 
parsers and other manipulation facilities, construction of support tools is convenient (see Section 3.5.1). 

3.23 Synthesis 

As stated earlier, the class of legacy systems that we are considering are command-line applications. Given 
this constraint, we make the assumption that any client applications utilizing the wrapped components have 
a certain amount of knowledge regarding the interface of that wrapped component. We find this assumption 
to be reasonable due to the nature of legacy software migration where legacy applications have an organiza- 
tional history with well-known usage profiles. 

We chose the Java programming language and environment as our target migration platform for a num- 
ber of reasons. First, Java continues to enjoy increases in popularity, and thus any opportunity to integrate 
legacy systems into Java applications has obvious benefits. Second, the object-oriented nature of Java fa- 
cilitates straightforward construction of components consisting of an aggregation, or federation, of wrapped 
legacy components. Finally, and most importantly, we found that the services provided by the Jini Con- 
nection Technology [Richards. 1999] for smart devices could also be applied to software components. As a 
result, software can be packaged as services on a Jini network and integrated dynamically into distributed 
applications. Accordingly, our approach for synthesizing wrappers for legacy components is based on im- 
plementing the standard discover and join protocol that is defined by Jini Interconnection Technology. 

In our approach, the information that is needed to generate wrappers corresponds exactly to the proper- 
ties associated with the ports shown in Figure 6. In addition to the Signature, Command (shown as Cmd in 
Figure 6), Pre, Post, and Path properties, we added the Interface, and Return fields. These fields de- 
fine the Jini service name of a port and the value returned after interaction with the port, respectively. In the 
synthesis process, ACME specifications are combined with a standard template that implements the setup 
routines that are required to register a service on a Jini network. In addition to synthesizing the appropriate 
wrapper, the support tool that we have constructed to automate this process generates the appropriate source 
code for facilitating interaction between a potential client and the wrapped component. At present, this is 
an automated tool that generates fully executable code for the wrapped application and does not require the 
user to modify or write any new code. 

While the investigations that are described here are limited to our efforts to adapt command-line ap- 
plications for use within a Jini-based software integration environment, we are pursuing investigations into 
broadening the context of this approach to other legacy software components including GUI-based appli- 
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Component RCS = { 

Properties { 

Component -type : string = "Call Return"; 

} ; 

Port Chkln = { 

Properties { 

Signature : string = "String filename, String params , String filedata ; 
Return : string = "Boolean result"; 

Cmd : string = "ci + filename + params"; 

Pre : string = "WriteFileData ( filedata , filename)"? 

Post : string = " " ; 

Interface : string = " versionManagement " ; 

Path : string = " C; WRKTOOLSWBINWCI .EXE ; 

Port-type : string = "callee"; 

Shared-GUI; string = "true"; 

};};}; 

Component Lzpr = { 

Properties { 

Component -type : string = "Call Return"; 

} ; 

Port Print = { 

Properties { 


}; }; ) ; 

Component Javac = { 

Properties { 

Component -type : string = "Call Return"; 

) ; 

Port Compile = { 

Properties { 


}; }; ); 


Figure 6: ACME Spec: Services Section 

cations. In addition, due to the ability of Java and consequently Jini to run anywhere, we are investigating 
approaches for automatically wrapping applications that exist within heterogeneous operating system envi- 
ronments. 

3.3 Client Generation 

Once the services are generated and stored in a repository, a client application can be architect-ed. First 
we need to specify the client application taking into account the architectural style of each of the services. 
Once a client is specified, it can be verified and generated. In this subsection we look at the requirements 
for specifying the client and then describe synthesis of the client. 

33.1 Specification 

Refer again to Table 1 which, in addition to the properties for service specifications, contains the prop- 
erties of client application components and connectors. When dealing with integration at the component 
level, two issues arise (among others) that are of interest. First, the problem of architectural style mis- 
match [Shaw and Garlan, 1996] occurs when the underlying assumptions made by components conflict. 
Second, most modern applications provide a graphical user interface (GUI). As a result, integration of 
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off-the-shelf components can leverage these user interfaces in order to take advantage of previously built 
technology. To cope with these issues we impose two requirements on the specification of client applica- 
tions. 

(Cl) The specification of the components should capture the notion of architectural style so that the high- 
level interaction between clients and services can be verified. 

(C2) The specification must facilitate the use of shared and exclusive GUI components. 

The requirement Cl addresses the fact that a component must provide a notion of architectural style. 
A component’s style plays a very important role when it interacts with other components by imposing 
interaction constraints. Using a basic style attribute, architectural mismatches can be determined by stating 
the assumption that a component is making regarding style. 

Requirement C2 addresses the fact that a service may provide a GUI that allows a user to access and 
control the service. In this context, there may be GUI components provided by services that are either 
shamble by other services or exclusive to the service. A sharable GUI component can be used by both the 
client as well as other integrated services while an exclusive GUI component can only be used by the service 
that provides the interface. 

332 Synthesis 

The second stage of our approach involves the synthesis of application code. Figure 7 shows a sample 
specification of a client. The information contained within client specifications are used to support the 
synthesis of client code. This synthesis step utilizes two features; First, the information regarding connectors 
and attachments, such as those shown in Figure 8 are used to determine the relationships between client 
applications and desired services. Second, information regarding GUI’s provided by services is used to 
determine how to realize the GUI in a client application. 

Both the service and client synthesis steps utilize a template-based approach to synthesize code. That is, 
a standard file has been created that has stubs containing place holders that must be instantiated with either 
service or client specific parameters. Figure 9 shows a piece of code (e.g., POC) for the client template and 
depicts the replacement points in with in ”()” tags. Given the nature of the code being generated (e.g., code 
used to realize integration between services and clients that utilize those services), we have found that this 
approach allows the developer to focus primarily upon client operation issues while delegating connector 
and integration concerns to automated tools. 

While a template-based approach lacks generality and freedom necessary to synthesize complex con- 
nector and integration code, the very nature of service-based components dictates a level of interaction that 
promotes loose coupling between components. In addition, at the core of service-based applications is the 
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Component Editor = { 

Properties { 

Part-of -client : string = "true"; 

GUI-CodeFile : string = M ClientGUICode . java" ; 

Component - type : string = "Call Return"; 

Shared -GUI : string = "true" ; 

}; 

Port VM_Port = { 

Properties { 

Port-type : string = "caller"; 

Interface : string = "VersionManagement " ; 

}; Im- 
port COMPILING_PORT = { 

Properties { Port-type : string = "caller"; 

}; 

Port PRINTING_PORT = { 

Properties { Port-type : string = "caller"; 

}; } ; 

Figure 7: ACME Spec: Client Section 

notion of common interfaces between clients and services. As a result, code that implements connection 
and integration operations can be easily parameterized, further leading towards a template-based software 
synthesis approach. 

3.4 Integration and Runtime Considerations 

3.4.1 Architectural Style Verification 

As mentioned earlier, specifications in our framework capture the style characteristics of components. To 
facilitate this verification a tool called Arch Verifier is used to verify that the styles of components are 
consistent. It does so by verifying that all the attachments between client and service components match. 
Our current implementation imposes an exact match criteria whereby components can only be connected 
to components of the same type. For example, a Call Return component can only be connected to other 
Call Return components through a Call Return connector. Our future investigations include expanding the 
verifier to allow for mappings of other types, where appropriate. 

3.4.2 Client Generation 

A client can be generated once the Arch Verifier validates the architecture. A synthesis tool called Generator 
makes use of a client template similar to the one shown in Figure 9 and fills the appropriate sections with 
the list of services (indicated by the (List of Services) tag) that are to be integrated with the client 
and the user-defined GUI components (indicated by the (GUI-CodeFile) tag) of the client. Typically, the 
developer of these client GUI components by the can assume that certain service classes provide common 
GUI facilities. However, the actual names of shared and exclusive GUI components need not be known by 
a client. 
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Connector checking_out = { 

Properties { Connector-type : string = "Call Return"; }; 
Role caller = { 

Properties { Prop-type : string = "output"; }; 

} ; 

Role callee - { 

Properties { Prop-type : string = "input"; }; 

)? } ; 

Connector checking_in = { 

Properties { Connector- type : string = "Call Return"; }; 
Role caller = { 

Properties { Prop type : string = "output"? }; 

} i 

Role callee = { 

Properties { Prop-type ; string = "input"; }? 

}; ) ; 

Connector compiling = { 

Properties { connector- type : string = "Call Return"; }; 
Role callee = { 

Properties { Prop-type : string = "input"; }; 

} 7 

Role caller = { 

Properties { Prop-type : string = "output"; }; 

}? } ; 

Connector printing = { 

Properties { Connector- type : string = "Call Return"; }; 
Role callee = { 

Properties { Prop-type : string = "input”; }; 

} ? 

Role caller = { 

Properties { Prop-type : string = "output"; }? 

}; }; 

Attachments { 

Editor .VM_Port to checking_in . caller ; 

Editor .VM_Port to checking_out.caller; 

Editor .COMPILING_ PORT to compiling . cal ler; 

Javac .Compile to compiling . callee; 

Editor . PRINTING_PORT to print ing . caller ; 

Lzpr. Print to print ing . callee ; 

Rcs.ChkOut to checking_out .callee ; 

Rcs.Chkln to checking_in . callee; 


Figure 8: ACME Spec: Connector Section 

3.43 GUI Integration 

Since many services can be GUI-bound, it is necessary to provide a facility for integrating the GUI compo- 
nents. In our framework, the adapters for the various services (as shown in Figure 14) implement a common 
interface that allows the client to get a handle on the shared and exclusive components of a GUI. Shared 
components are potentially used across multiple services and are identified using a name taken from a stan- 
dard GUI vocabulary (for example “Code Window” or “Results Window”). The name is then used to identify 
which GUI components can be shared across services. Such shared components facilitate the integration of 
the GUI components by allowing reuse of widgets that provide the same functionality. An exclusive compo- 
nent is independent and cannot be shared between services. The exclusive GUI components of the adapters 
are used as is but may interact with one or more of the shared components. For both shared and exclusive 
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public class MyClient 
{ 

static String [] services = <ListOf Services> ; 
static Hashtable state = new HashtableO; 

<addClientComponentFuncs> 

public static void main (String[] args) 

{ 

//discover and join the jini network. 

//discover all the services on the network 
//and get the adapter for the service. 


} 

private static boolean already Added (String key) 

{ 

//check if a shared component 
// with key has been added. 


private static boolean inMyList { String serviceName) 

{ 

// verify if the serviceName is in the 
// list of services. 


} 

} 

Figure 9: Client Template POC 

components, the interaction with the client GUI and application is seamless since the adapters handle direct 
interaction with the services while the client need only interact with the adapters. 

3.5 Implementation 

In this section we discuss the implementation aspects of the service generation and the client generation 
using tools that we have built. 

3.5.1 Service Generation 

To support our technique for constructing wrappers for legacy software, we have created a Java support 
tool called ServiceTool. Figure 10 shows the detailed architecture of ServiceTool which takes an ACME 
specification and produces a wrapper configured for a Jini network. In the diagram, the rectangles with 
the square comers represent software components while the rectangles with the rounded comers represent 
files. The ArchParser component reads in an ACME specification similar to the one shown in Figure 6 and 
builds an internal model of the architecture. The Component Inspector component uses the output of the 
ArchParser to access the interface specification of the wrapper component and produces a set of ports. The 
Interface Generator component uses the set of ports to generate the interface or connector to the service. 
The Function Generator component uses the same port information to generate functions that implement the 
service. The Service Generator component uses these functions along with the ServiceTemplate to generate 
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the final Java source code for the service. 



Figure 10: Service Tool Architecture 


The ArchParser uses the ACMEParser from the ACMELib toolkit [Acme Lib, 1997] to parse ACME 
specifications. ACMELib is a library that facilitates the construction of architectural tools in Java that read, 
write and manipulate software architectures specified in the ACME ADL. The ACMELib framework is 
designed to support the rapid development of two classes of applications (1) tools that translate between 
’’native” ADLs (such as Rapide [Luckham and Vera, 1995] and Wright [Allen and Garlan, 1997]) and (2) 
native ACME-based architectural design and analysis tools. 

The Service Generator component is implemented as an awk script that replaces tags in the ServiceTem- 
plate file with functions generated by the Function Generator component and the names of services. 

Figure 1 1 contains a portion of the ServiceTemplate file which contains all of the application and service 
independent source code and provides the routines necessary to integrate the legacy code into a Jini net- 
work. Specifically, the ServiceTemplate contains functions that implement the discover and join protocol for 
registering a service with the lookup service. The ServiceTemplate also contains tags that are place-holders 
for the automatically generated functions. For instance, in Figure 11 the tag <put-ServerName> is a 
place-holder for the final name of the adapter component. 

In addition to the ServiceTemplate, there is also a reusable set of functions that can be utilized in an 
interface specification and consequently in the generated wrappers. For instance, the ReadFileData ( ) 
and WriteFileData ( ) routines (shown in Figure 12), are available as functions for use within the Java 
code to provide standard read-from and write-to file support, respectively. 
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public class <put-ServerName> extends UnicastRemoteObject 

implements <put-InterfaceName>, ServicelDListener , Serializable 

{ 

public <pu t - Se rverName > <) throws RemoteExcept ion 

{ 

super { ) ; 

} 

<put-Functions> 

Figure 11: Excerpt of the ServiceTemplate 


void WriteFileData (String filedata, String filename) { 
// the generic WriteFileData.. 


try { 

File f = new File(filename); 

System. out .println (" IsFile {): " + f.isFileO); 

PrintWriter out = new PrintWriter{ new FileOutputStream ( f ) , true), 
out .print { filedata) ; 
out . close ( ) ; 

} 

catch (Exception e) 

System. out .println ("Server: Error writing file: ” + e) ; 

} 

} 


String ReadFi leData ( String filename) { 

try{ 

Buf feredReader in = new Buf feredReader (new FileReader ( filename )) ; 
String s; 

StringBuffer sb = new StringBuffer (); 


) 


while ( (s =in . readLine { ) ) ! = null ) 

{ 

sb. append (s ) ; 
sb . append { " \n " ) ; 

} 

in . close ( ) ; 

// returning the whole file as a string., 
return (sb . toString { ) ) ; 

} 

catch (Exception e) 

{ 

System. out .println ("Server: Error writing file: 
return { "Server : Error writing file: "+ e) ; 


e) ; 


Figure 12: Sample Library Routines 


3.5.2 Client Generation 


To support the construction of client applications, we have created a support tool written in Java called 
ClientGenTool. Figure 13 shows the detailed architecture of the ClientGenTool which takes an Acme archi- 
tecture (specification) and produces a Client source. In this figure, the rectangles with the square comers 
represent software components while the rectangles with the rounded comers represent data stores or repos- 
itories. 
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Figure 13: ClientGen Tool Architecture 

The ArchParser reads in ACME architecture specifications similar to the ones shown in Figures 6, 7 
and 8 and builds an internal model of the architecture (Internal Arch). The ArchParser uses the ACMEParser 
from the ACMELib toolkit [Acme Lib, 1997] to parse ACME specifications. The Arch Verifier uses the 
Internal Arch model to verify the style of the architecture based on the Component-type and the Port-type 
properties. Once it is verified, the Extract component identifies the Client Component, Client GUI , and the 
List of Services from the Internal Arch model. All these are used by the Generator component along with 
Client Template to produce the Client Source. 

4 Examples 

To demonstrate the use of the integration technique described in this paper, we have created two examples, 
a simple editing application and a simple network monitoring example. 

The intent of the simple editing application is to support text file editing with version control, compi- 
lation and printing facilities. The intent of the simple network monitoring example is to monitor various 
servers on a network by creating a consolidated console using simple administration tools running on the 
servers. All the services were generated using ServiceGenTool [Gannod et al., 2000] while the client appli- 
cations were generated using ClientGenTool. 

4.1 Editing Application 

Figure 14 shows the conceptual architecture of the editing application. The client application interacts with 
services via each of their respective adapters. The adapters provide GUI components that are integrated by 
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the client to render the client application. These GUI components may interact with components from other 
services (e.g., they may be shared or exclusive). If a GUI component is exclusive, it must be integrated 
directly by the client as required by the service. If the GUI component is shared, it may be used only if a 
similar component does not already exist. For example, the RCS service adapter provides a shared editing 
panel component named “Code Window”. If the client already has a “Code Window” component, the shared 
component from the RCS service adapter is not used. 



Figure 14: Conceptual Architecture: Editing Application 

4.1.1 Specification 

Figures 6-8 contain portions of the specifications used to describe and generate the editor application. As 
shown in Figure 7, the Editor component is a Call Return component, as indicated by the Component-Type 
property. The Editor component has three ports, namely VM.Port, COMPILING_port, and PRINT - 
ING.port. These ports correspond to the services that the editor seeks to bind with at run-time. 

The connectors checking_out, checking_in, printing, compiling, shown in Figure 8 con- 
nect the editor to the appropriate version management, printing, and Java compilation components, re- 
spectively. The Connector-Type for these connectors must match the Component-Type property of the two 
components it connects. The attachments section in the specification (shown in Figure 8) describes the 
attachments between roles and ports. While the specification shown in this examples identifies specific 
services, attachments can actually be made to generic components that identify a class of services. 

4.1.2 Client Application 

The ClientGenTool generates the client using specifications similar to the ones described above. Once 
generated, the client becomes the focal point for the integration of the various services. Specifically, at run- 
time the client joins a Jini network and looks for services with which to integrate. Once found, the services 
are bound via an adapter and the GUIs are integrated along with the GUI provided by the client. Figure 15 
depicts the editing application as a result of executing the client side code. In this case, the client has been 
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executed on a Jini network that does not have any of the desired services available. 



r 

Editor Window.. 



Figure 15: Client by itself 

4.1 3 Integration and Execution 

As each service is executed it joins a Jini network, the client learns of its existence and integrates with it 
by interacting with the corresponding adapter. The service adapter provides GUI components that can be 
either exclusive or shared. In the case of exclusive components, they are used as is. In the case of shared 
components, they may be used in lieu of another similar component. Figure 16 shows the result of the 
integration once all the services have joined the Jini network. 

Once all the services have been integrated, the application appears as shown in Figure 16. In the diagram, 
the top text pane is the original editing window provided (and shared) by the client. The buttons directly 
below the top text pane are provided by the RCS service and the Javac service, respectively. The middle and 
bottom text panes are exclusive GUI components needed by the Javac and Lzpr services. 

Getting the client application to integrate with the set of services requires that the Jini network must be 
up and running along with an associated lookup service. Since Jini is build on top of Java RMI, an RMI 
daemon must be running prior to execution of the lookup service. Finally a web server must be running in 
order to enable code delivery across the Jini network. 

4.2 Network Monitoring Example 

Figure 17 shows the conceptual architecture of the network monitoring application. Similar to the simple 
editing application, the client application here interacts with services via each of their respective adapters, 
each of which provide GUI components that are integrated to render the client application. This application 
integrates the following services: TopService, UpTimeService and TcpDumpService. The TopService pro- 
vides the top CPU processes information using the top command. The UpTimeService provides information 
about how long a system has been up along with the load average using the uptime command. The Tcp- 
DumpService provides a dump of the traffic on network using the tcpdump command. Each of these services 
executes on different machines on a network. The network monitoring client integrates these services and 
provides a unified client that then enables a user to monitor the machines. 
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4.2.1 Specification 


Figure 16: Client after Integration 


To build this application, we constructed specifications similar to those found in Figures 6- 8. In this exam- 
ple, a monitoring client is connected to the TopService, UpTimeService and a TcpDumpService via connec- 
tors. The monitoring client is a CallReturn component, as are the services TopService, UpTimeService and 
TcpDumpService. 


4.2.2 Client Application 

The Client Application is connected with TopService via a get_top connector to the TOP-Port. Sim- 
ilarly the client application is connected to the UpTimeService via a get_uptime connector to the UP- 
TIME_Port and to the TcpDumpService via a get-tcpdump connector to the TCPDUMPJPort. The 
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Figure 17: Conceptual Architecture: Network Monitoring Application 
produced specification is used by the ClientGenTool to generate a client. Each of the services provide 

exclusive GUI components namely ’’TopResults”, ’’UpTimeResults” and ’’TcpDumpResults . 

4.23 Integration and Execution 

The client when executed becomes the focal point for the integration. When the client comes up on the Jini 
network, it looks for the TopService, UpTimeService, TcpDumpService. As each of these services become 
available on the network, the client is notified and is bound with the adapter provided by the service. The 
adapter is used by the client to reach and interact with the service. The GUI components are also integrated 
using the shared and exclusive GUI components that are provided by the services. Figure 18 shows how the 
network monitoring client would look once all the services are available and integrated by the client. 

4.3 Discussion 

In the examples described above, the effort needed to generate the services was centered primarily upon 
the creation of the appropriate specifications as well as the code needed to provide a GUI interface to the 
service. In the client applications, the effort was likewise focused. However, as demonstrated by Figures 15 
and 16 no effort (e.g., no extra code) was necessary to realize final GUI and application integration outside 
of the client application specific GUI, which for the editor application amounts to just a text pane and for 
the network adminstration application amounts to a frame panel. 

In comparison to a “one-time” application development, the amount of code development in the service- 
based approach required less effort since the adapter and glue code for service and client components is 
automatically generated. In comparison to development of applications that utilize existing services, the 
amount of effort required is greatly reduced since each subsequent application (assuming existence of ser- 
vices) is limited to client specification and code development. 

With regards to other component and middleware technologies, the approach used here has the advantage 
of supporting seamless integration based on availability of services. However, along with other service- 
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Figure 18: Network Monitoring Application 

based technologies including web services, has the disadvantage of assuming loose coupling, thus relying 
heavily upon a priori knowledge regarding service behavior and data integration concerns. 

5 Related Work 

Recently, the use of WebServices [Oellermann, Jr., 2001] has gained attention with vendors releasing web- 
services toolkits that allow for building and using webservices. Webservices are based on the SOAP and 
XML [Seely and Sharkey, 2001] protocols over transport layers such as HTTP and HTTPS. Our approach to 
service integration goes beyond what the webservices paradigm provides. It does not talk about how to use 
the applications but rather what these services provide and where they reside. We take a step further in that 
we also try to define how these services need to be used with a larger context of several kinds of services. 
We make use of the ability to transport code provided by the Jini technology. 

An interesting area of research work namely Semantic Web [Semantic Web, 2002] has also started to 
gain a lot of momentum. The Sematic Web is an extenstion to the existing web as it exists today, in that it 
allows the information to be given a well-defined meaning, allowing computers and people to work together. 
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The DAML [DAML, 2002] is an agent markup language that is a first step in trying to specify information 
that can be interpreted by computers as opposed to humans. 

Jacobsen and Kramer [Jacobsen and Kramer, 1998] describe an approach for synthesizing wrappers 
based on the specification of a modified CORBA IDL description. In their approach, they address the 
problem of object synchronization within the context of the CORBA standard and define a technique based 
on the application of the adapter design pattern. In many ways, Jacobsen and Kramer’s approach is similar 
to the one described in this paper. We are currently interested in software at a higher level of granularity than 
the ones often provided via ORB-based interfaces, thus our approach has some potential for full automation. 
However, as we increase our scope to include a more general class of component, we must address similar 
concerns. 

Thakkar et al. describe the Ariadne service-specification language and process and the Theseus service- 
execution platform [Thakkara et al., 2002]. Ariadne adopts a relational-database view of existing resources 
and supports the construction of wrappers treating these resources as relational databases. Resources speci- 
fied in Ariadne can be combined in terms of data-flow specification and these compositions are executed at 
run-time by their Theseus environment. They look at data integration as opposed to behavioral integration. 

Sullivan et al. look at systematic reuse of large-scale software components via static component inte- 
gration [Sullivan et al., 1997]. That is, they use an OLE-based approach for component integration. To 
demonstrate the use of their scheme, they developed a safety analysis tool that integrates application com- 
ponents such as Visio and Word. In our approach we use a dynamic approach for component integration and 
thus, can utilize a wide variety of components whose interfaces are discovered at run-time. 

CyberDesk [Dey et al., 1998] is a component-based framework written in Java that supports automatic 
integration of desktop and network services. This framework is flexible and can be easily customized and 
extended. The components in this framework treat all data uniformly regardless of whether the data came 
from a locally running service or the World Wide Web. The goal of this framework is to provide ubiquitous 
access to services. This approach is similar to our proposed approach in that they use a dynamic mapping 
facility to support run-time discovery of interfaces. 

Finally, Grechanik et al. describe ways to integrate and reuse GUI driven applications [Grechanik et al., 2002] 
by wrapping applications as objects and accessing them programatically via an API. They achieve this using 
interceptors that capture GUI events which can be later replayed. In comparison, our approach achieves 
GUI integration by requiring that services on a Jini network provide a GUI via an adapter and proxy. The 
GUI integration is realized by using Jini’s built-in facility for transporting direct handles to the proxies and 
integrating them directly into client applications at run-time. 
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6 Conclusions and Future Investigations 

The web-based services paradigm has gained attention recently with the development of technologies such 
as SOAP [Seely and Sharkey, 2001]. The benefits of such technologies has obvious advantages such as 
application sharing, reuse, and inter-operability between organizations. Services extend these benefits by 
providing facilities for on-the-fly integration and component introspection. In this paper, we described an 
approach for addressing component integration via the use of services in the context of Jini Interconnection 
Technology. Specifically, the approach utilizes synthesis to generate code necessary to realize component 
integration as well as GUI integration. To facilitate integration, the ACME ADL is used to specify both 
services and target applications, and is used a medium for performing service compatibility checking. 

We are currently developing an environment that will assist in the creation of applications within the 
service-based paradigm and will support service browsing to facilitate application design [Mudiam et al„ 2002], 
In addition, we are investigating approaches for allowing services to collaborate beyond the scope of a client 
application in order to create federated groups of services. Furthermore, we are developing technologies 
similar to the ones described in this paper in order to support service-based application within the .NET and 
web service frameworks. 
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